A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The present invention is related generally to communications across a computer system network and more specifically to methods for managing components in a heterogeneous computer system network.
2. Description of Related Art
A current trend in computing is to interconnect a variety of computer architectures and computer operating systems in a single network 100. As illustrated in FIG. 1, network 100 includes a variety of servers, i.e., a Unix server 150, a Netware server 160, an OS/2 server 170, and a Windows NT server 180. Herein, network 100 and similar networks are referred to as heterogeneous networks. Heterogeneous networks include local area networks.
One configuration commonly used for performing operations over a network, such as network 100, is a client/server architecture. A server process executing on a server computer is a provider of services. Servers include file servers, database servers, transaction servers, groupware servers and object servers.
A client process, that is executing either on a server computer or another computer, is a consumer of services provided by the server. Thus, in FIG. 1, three computers 110, 120 and 130, that are each running a client process, are illustrated.
Clients and servers are loosely coupled systems that interact over network 100. Each interaction between a client and a server tells a server which service is requested. After the server receives the request, the server determines how to perform the service specified in the request.
Communications between a client and a server over heterogeneous network 100 require a method for transporting requests over network 100 from a client running under one operating system to a server that is either running under another operating system, or the same operating system. One widely used method for communication over heterogeneous network 100 is a remote procedure call (RPC). Techniques for implementing client/server applications, and client/server applications with remote procedure calls are known to those skilled in the art. A remote procedure call (RPC) hides the physical structure of network 100 and makes a server on network 100 appear to be one function call away. Specifically, a remote procedure call hides the details of network 100 by using a procedure call mechanism that is well known.
A common way to illustrate implementation of a remote procedure call is a stack. FIG. 2 is an example of one prior art representation of a stack 200 that includes two common implementations of a RPC. One widely used RPC standard is distributed computing environment (DCE) RPC (FIG. 2). A DCE RPC allows a client to interoperate with one or more servers on other computing platforms, even when the client and server are from different vendors with different operating systems.
DCE is associated with an interface definition language (IDL) and compiler that facilitate creation of RPCs. The IDL compiler creates source code stubs for both the client and server sides of an application. The stubs are compiled and linked to the RPC run-time library, which is responsible for finding servers in a distributed system, performing the message exchanges, packing and unpacking the message parameters, and processing any errors that occur. The DCE RPC does not support transactions.
One problem encountered in using RPCs is the representation of data across a network with multiple platforms, because different CPUs represent data structures differently, for example, Big-Endian versus Little-Endian. To maintain machine independence, the RPC uses some level of data format translation across systems.
With DCE, the client chooses one of the multiple data format representations from the network data representation (NDR) service. (See FIG. 2.) The client chooses the data format, typically its own native data representation; tags the data with the chosen format; and the server must transform the data into a format that the server understands.
Another common RPC is provided by Sun Microsystems of Mountain View, Calif. RPC on Sun Microsystems computers requires that the client convert the data to a neutral canonical format using an external data representation (XDR). (See FIG. 2.) With the Sun approach, all clients look the same to a server. In FIG. 2, NetBios, sockets and transport layer interface (TLI) are all interfaces between RPC and the various network transport stacks. Network transport stacks include TCP/IP, NetBIOS, IPX/SPX, DECnet, AppleTalk, OSI, and SNA/APPN, for example. There is a logical interface to the network device drivers at the bottom of the network transport stack. Examples of widely supported logical interfaces to network device drivers are Microsoft/3Com's NDIS and Novell's ODI. The remainder of the standards, drivers, and communication protocols in FIG. 2 are known to those of skill in the art and are shown only for completeness. A more complete discussion of transport stacks is provided, for example, in Tannenbaum, Computer Networks, Prentice Hall, (1988). Herein, a network stack refers to network stack 250.
RPCs are used widely. However, for desktop management of components within a single desktop computer system, another approach is used. A Desktop Management Interface (DMI) has been defined by the Desktop Management Task Force, MIS JF2-51, 2111 N.E. 25th Avenue, Hillsboro, Oreg. 97124. DMI is a local interface between management applications that manipulate information on components, e.g., physical or logical entities in a computer system, and the components. For a detailed description of DMI, see the Desktop Management Interface Specification, Version 1.0, Apr. 29, 1994, which is incorporated herein by reference in its entirety.
FIG. 3 is a block diagram of DMI within computer system 300. Management applications 301-1 to 301-n use a management interface 310 to manage components 302-1 to 302-i within computer system 300. Management applications include a management console, a desktop management application, and a local area network management application. In general, a management application is a remote or local application that changes, interrogates, controls, tracks, or lists components of a desktop computer system.
Management interface 310 shields management applications 301-1 to 301-n from the different mechanisms used to obtain management information from components 302-1 to 302-i within computer system 300. Typical components include software applications, operating systems, hardware products, peripheral products, and system hardware. Each component has a management information file (MIF), that describes the manageable characteristics of the component, stored in a MIF database 340 within computer system 300.
Management interface 310 is a data interface, as opposed to the procedural interface used in a RPC. Data blocks describe the format for data transfer instead of parameters to a function call. Thus, a command is issued from a management application, for example, management application 301-1, to build a data block and pass the data block to service layer 320. All commands are specified with data blocks, but there is one function call provided to pass the command to service layer 320.
Service layer 320 is a desk-top resident application that controls the flow of information between management interface 310 and a component interface 330. Service layer 320 is a permanent background process that is always ready to handle an asynchronous request. The operations of the service layer are documented in Chapter 2 of the Desktop Management Interface Specification.
Component interface 330 receives calls from service layer 320. Component interface 330 also is a data interface, and so data blocks describe the format for data transfer. Communication between component interface 330 and service layer 320 is operating system dependent.
While DMI provides a useful function for the desktop, the data interface, i.e., command blocks, is a departure from RPC. The current trend for management of components in a heterogeneous network is to use RPC.
FIG. 4 is a block diagram of a client/server architecture used over a network, e.g. a heterogeneous network, to manage hardware components. A remote client application 411, that needs to interact with a hardware component on server computer 420, uses RPCs to communicate over heterogeneous network 400 with server computer 420.
For example, remote client application 411 is a graphic user interface (GUI) such as that used on a Windows workstation. A remote I/O management application programming interface 412 (IOMAPI 412) is provided to remote client application 411 by a remote client interprocess communication module 413.
IOMAPI 412 includes general I/O management functions, RAID management functions, and an administration application programming interface (API). The functions available to remote client application 411 in IOMAPI 412 are the same as those made available to a local client application 435 on server computer 420 by server IPC module 423. Function calls to IOMAPI 412 by remote client application 411 result in I/O management on server computer 420. The administration calls by remote client application 411 through IOMAPI 412 are used for establishing a network session, and for ensuring the authentication and access rights of applications issuing IOMAPI calls.
A call to a function in IOMAPI 412 by remote client application 411 is passed to RPC command client 414. RPC command client 414 packages the function call in a conventional fashion and transmits the packaged function call to network stack 415, which in turn controls transmission of the packaged function call over network 400 to network stack 425 of server computer 420.
To package the request, RPC command client 414 converts the function call and any associated data to a neutral canonical format using an external data representation (XDR). Thus, in FIG. 4, IOMAPI 412 and RPC command client 414 are functionally the RPC layer of FIG. 2.
Network stack 425 transmits the packaged function call to server RPC command module 424. Server RPC command module 424 extracts the function call from the packaged request. If the function call is an administration function call, server RPC command module 424 processes the administration function call and replies to RPC command client 414 that in turn communicates with remote client application 411. However, if the function call is an IOMAPI function call, server RPC command module 424 passes the function call to server IPC module 423 Server IPC module 423 transfers the specified function call via a message buffer IPC.sub.-- MESSAGE to an I/O manager 430 with an interface to server IPC module 423. Message buffer IPC.sub.-- MESSAGE, sometimes called message IPC.sub.-- MESSAGE, is transmitted using an interprocess communication. In response to message IPC.sub.-- MESSAGE, I/O manager 430 issues a call to the appropriate management function.
I/O manager 430 performs the called management function and returns the result to server IPC module 423. The results are returned from server IPC module 423 to remote client application 411 in the normal manner for a RPC.
While the architecture of FIG. 4 overcomes the limitations of DMI by using a RPC mechanism, the use of RPCs introduces limitations on updates and modifications. Any change in remote IOMAPI 412 and/or local IOMAPI 422 requires a change in RPC command client 414 and RPC command module 424. Any change in RPC command client 414 and RPC command module 424 implies changes in remote client application 411. The RPC interface must support every single command that's defined in the list of procedure calls for every possible version and must support every one of the parameters that are passed with each of these procedure calls.
Hence, RPC may not work properly in an environment with mixed versions of remote IOMAPI 412 and local IOMAPI 422. To assure version capability across heterogeneous network 400, remote client IPC module 413, client RPC command module 414, server RPC command module 424 and server IPC module 423 must be updated to support each version, recompiled, and relinked for each of the computers on network 400. For heterogeneous networks, this is a formidable task. Thus, while the trend is to implement RPC for component management over a heterogeneous network, the requirement of the current RPC architecture for either consistent versions or support of all versions throughout such a network will limit the actual utilization of RPC for component management.